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Service Selection Gateway (SSG) Supporting Tariff 
Changes for Traffic Volume 

Related Application 

The present application is related to the commonly owned co-pending US patent 
application serial number: 10/418,719, entitled, "Flexible Billing Support in a Service 
Selection Gateway (SSG)", filed on: 4/1 8/2003, naming as inventors Ravindranath et al 

Background of the Invention 

Field of the Invention 

The present invention relates to telecommunication networks, and more 
specifically to a service selection gateway (SSG) which supports tariff changes for traffic 
volume. 

Related Art 

Service selection gateways (SSG) generally refer to network switches/routers 
which allow a subscriber to selectively access various services on the Intemet. In one 
common environment, an access provider (e.g., an intemet service provider or a shop 
providing the subscriber terminals to access the services) controls the services a 
subscriber is permitted to access, and bills the subscriber for accessing/using the services. 



In an approach generally referred to as a postpaid model, a subscriber is permitted 
to access various services and charged later (for example, after termination of a session, 
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monthly, weekly, etc.) for the traffic volume transferred. The traffic volume may specify 
the number of bytes sent and/or received. 

A prior SSG may be designed to support a constant tariff for traffic volume. In 
general, a tariff refers to a schedule of prices for a unit of each resource used, and a 
5 constant tariff implies that the prices are fixed. In such a model, a SSG may send 
accounting records (either periodically or at the end of a session) indicating traffic 
volume. The accounting records may be stored in a database and the subscriber may be 
charged later based on the stored records. 

Brief Description of the Drawing s 

10 The present invention will be described with reference to the accompanying 

drawings, wherein: 

Figure 1 is a block diagram illustrating an example environment in which the 
present invention can be implemented; 

Figure 2 is a flow chart illustrating a method by which SSG supports tariff changes 
15 in postpaid service in an embodiment of the present invention; 

Figure 3 is a timing diagram illustrating the details of accounting records in an 
embodiment of the present invention; 

Figure 4 is a block diagram illustrating the internals of an embodiment of a service 
selection gateway (SSG) provided in accordance with the present invention; and 
20 Figure 5 is a block diagram illustrating the details of an embodiment of a service 
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selection gateway implemented substantially in the forai of software according to an 
aspect of the present invention. 

In the drawings, like reference numbers generally indicate identical, functionally 
similar, and/or structurally similar elements. The drawing in which an element first 
appears is indicated by the leftmost digit(s) in the corresponding reference number. 

Detailed Description of the Preferred Embodiments 

1. Overview 

A service selection gateway (SSG) provided according to an aspect of the present 
invention receives data representing various tariff switching points (i.e., the time point at 
which tariff changes), and sends accoimting records indicating traffic volimie up to or 
after each switching point. The accounting records can be used to charge subscribers 
according to the corresponding varying tariff. Thus, for example, a service provider may 
charge more when an access network is likely to be used more and less in other durations. 

In one embodiment, a SSG sends an accoimting record indicating the traffic 
volume for an entire duration with constant tariff. Thus, assuming that a user accesses 
service(s) an entire day and three different tariffs are applicable in a day, three accounting 
records may be generated indicating the traffic voliraie in each of the three durations. 



One problem with such an embodiment is that the SSG may have to perform 
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substantial amount of processing (e.g., to send accounting records) at switching points. 
The amount of processing may be particularly unacceptably high when a SSG has to 
support many (e.g., several thousands) of subscribers. 

In an altemative embodiment, a SSG sends two counts associated with each 
subscriber (or service or connection), with one count ("aggregate count") indicating the 
total traffic volimie since the start of a session and another coimt ("marginal coxmt") 
indicating the traffic volume since the last switching point. The two counts are sent at 
least once in each tariff duration (i.e., between two switching points). The two counts can 
be used to accurately determine the traffic volume in each tariff duration, and the 
subscriber may be charged according to the varying tariffs as desired. 

In one implementation of an SSG sending both aggregate count and marginal 
count, the SSG may maintain the corresponding two counters, which are both updated 
upon forwarding each packet. One problem with such an implementation is that, the 
overhead of updating both the counters (for every packet) may be unacceptably high. 
Accordingly, in an altemative implementation, an SSG maintains only one coimter 
intemally and the counter values (counts) are stored at each switching point. The 
marginal count may be computed by subtracting the stored counter value at the prior 
switching point from the aggregate counter value at the time of sending the accounting 
record. 
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Several aspects of the invention are described below with reference to examples 
for illustration. It should be understood that numerous specific details, relationships, and 
methods are set forth to provide a full understanding of the invention. One skilled in the 
relevant art, however, will readily recognize that the invention can be practiced without 
one or more of the specific details, or with other methods, etc. In other instances, well 
known structures or operations are not shown in detail to avoid obscuring the invention. 

2. Example Environment 

Figure 1 is a block diagram illustrating an example environment in which the 
present invention can be implemented. The environment is shown containing subscriber 
systems 110 and 120, subscriber edge service manager (SESM) 130, authentication, 
authorization and accoimting (AAA) server 140, service selection gateway (SSG) 150, 
database 160, and service networks 170 and 180. Each system is described in further 
detail below. 

Service networks 1 70 and 1 80 typically contain many servers (not shown) such as 
web servers, application servers and network devices (e.g., routers), which together 
provide various services (e.g., video applications, database applications, teleconferencing, 
etc.). Merely for simplicity, it is assumed that a user need not be authenticated for 
individual services. However, altemative embodiments may be implemented to extend 
the user interface to require a user to send specific information required for authentication 
for the specific service as well. 
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Each of subscriber systems 1 10 and 120 represents a system such as a personal 
computer (PC) often comiected to intemet using technologies such as DSL and dial-up 
connections on path 115. A subscriber may access services provided in the servers 
present in service networks 1 70 and 1 80 using subscriber systems 1 10/120. As described 
5 below, an aspect of the present invention enables subscribers to be billed with varying 
tariffs for the traffic volume (bytes sent/received) generated due to accessing such 
services. 

SESM 130 provides an interface for a subscriber to send any necessary information 
(e.g., user identifier and password) for authenticating the subscriber. The provided 

10 information is sent to AAA server 140 by SSG 150. An authentication confirmation 
message fi*om AAA server 140 may fiuther indicate a list of services the subscriber is 
allowed to access. SESM 130 may then enable the subscriber to select the desired 
service(s) of interest by a suitable interface, for example, by sending a HTML page to a 
web browser executing on subscriber system 1 10/120. SESM 130 indicates the selected 

15 service along with the subscriber identification to SSG 150. Altematively the user may 
be logged on to certain services by default without explicit service selection required at 
SESM 130. 

AAA server 140 receives accounting records related to various subscribers and 
stores the contained information in database 1 60. The accounting records can be used to 
20 charge subscribers for traffic volumes using varying tariffs. AAA server 1 40 may be used 
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to send data representing switch-over points between different tariffs, as also described 
in sections below with examples. 

In addition, AAA server 140 authenticates the subscriber based on information 
received from SESM 130. AAA server 140 then sends a response containing a list of 
5 services (with corresponding service identifiers) the subscriber is permitted to access to 
SSG 150. AAA server 140 may be implemented based on RFC - 2865, entitled, "Remote 
Authentication Dial In User Service (RADIUS)", available fi-om www.ietf org . 

SSG 150 forwards packets between various systems (subscriber systems 1 10/120, 
SESM 130 and AAA server 140) when the subscriber is being authenticated and when 
10 the subscriber selects a service of interest to access. SSG 150 may thus receive a 
subscriber identifier and a service identifier(s) from SESM 130. SSG 150 enables 
subscriber to access various services (including those specified by SESM and any others 
accessible by all/group). 

An aspect of the present invention enables acciu'ate billing of subscribers for traffic 
1 5 volume according to tariffs which change by time. The feature(s) may be appreciated by 
understanding the operation of a prior system which may not provide one or more of such 
features. Accordingly such a prior embodiment is described below. 



3. Prior System Not Providing One or More of Features of the Present Invention 
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A prior SSG may send accounting records (for a subscriber, connection or service) 
containing traffic volume to an AAA server periodically (e.g., every 1 5 minutes) without 
regard to tariff switching points. One problem with such an embodiment is that a single 
accounting record may have a coimt representing a traffic volume transferred in two (or 
multiple, in general) tariff durations (i.e., having different charges), and it may not be 
possible to accurately determine the portion of the traffic volume transferred in each of 
the durations corresponding to the different tariffs. 

As a result, the charges to a customer may not precisely reflect the volumes of 
traffic transferred in the respective tariff durations, which may be undesirable at least in 
some situations. An aspect of the present invention enables a SSG to accurately charge 
subscribers according to desired tariff changes, as described below in fiuther detail with 
reference to examples. 

4. Method 

Figure 2 is a flow chart illustrating a method using which a SSG may support tariff 
changes associated with different times of access of a service according to an aspect of 
the present invention. The flow-chart is described with reference to the systems of Figure 
1 for illustration. Various aspects of the invention can be implemented in other 
environments as well. The method begins in step 201, in which control immediately 
passes to step 210. 
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In stqp 210, SSG 150 receives data representing tariff switching points, i.e., the 
time points at which tariffs change. The switching points may be represented using one 
of several approaches. In one embodiment, specific time points (such as 8.00AM, 
9.00PM and 1 1 .00PM) in a day may be specified as the switching points. Alternatively, 
the same switching points may be specified in terms of time duration starting with mid- 
night (i.e., 8 hours, 21 hours and 23 hours). In addition, different switching points may 
be specified for different days/months/weeks, etc., as desired by a service provider. 

In step 250, SSG 150 counts the volume (number of bytes or packets) of traffic in 
relation to (i.e., up to or from) each switching point. In step 280, SSG 150 sends 
accounting records containing the counted numbers, for example, to AAA server 140. 
As the information in the accounting records is in relation to each switching point, the 
traffic volume in each tariff duration may be computed accurately. The method ends in 
step 299. 

In an embodiment, each accounting record, contains a single niunber from which 
the traffic volume in each tariff duration may be determined. For example, SSG 1 50 may 
send the value of a counter at each switching point, and thus the traffic volume in each 
switching point may be determined by merely subtracting numbers from two successive 
accounting records. Altematively, the covinter may be reset at each switching point such 
that the traffic volume may be provided by a single number in each accounting record. 
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One problem with such an embodiment(s) is that SSG 150 may need to perforai 
a substantial amount of processing at each switching point, which may be undesirable. 
An altemative approach at least overcomes such a disadvantage by sending two counts 
for a traffic volume sought to be measured, as described below with reference to Figure 
5 3. 

5. Multiple Counts 

Figure 3 is a timing diagram illustrating the manner in which traffic volume may 
be accurately measured for each switching point according to an aspect of the present 
invention. Broadly, in one embodiment, SSG 150 sends two counts associated with each 
10 traffic volvime (per subscriber, service or connection, as desired), with a first coimt 
("aggregate count") indicating the aggregate nxmiber of bytes (or packets) since 
initialization and the second count indicating the traffic volume since the last switching 
point. 

Continuing with reference to Figure 3, it is assumed that the tariff data contains 
1 5 three switching points (depicted as broken solid lines) as shown by 320, 330 and 340 for 
illustration. Thus, the entire time duration contains four tariff durations - first one up to 
time point 320, the second one between time points 320 and 330, the third one between 
time points 330 and 340, and the fourth one from time point 340 onwards. It is also 
assumed that the subscriber is logged on to access a service at time point 310 (before 
20 switching point 320) and logged off at time point 350 (after switching point 340). 
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In operation, SSG 150 sends the two counts at least once in each tariff dviration. 
It is assumed that the two counts are sent at time points 312, 323, 334, 345, and 350 
("accounting points", shown as dotted lines), with the corresponding aggregate counter 
values being represented by A1-A5 and the marginal counts (counted from a previous 
5 switching point) being represented by M1-M5. 

AAA server 140 receives the two counts and computes the traffic volvmie in each 
tariff duration based on the coimts. As may be readily observed, the respective traffic 
volumes T1-T4 in tariff durations 310-320, 320-330, 330-340, and 340-350 may be 



computed by the following equations: 

10 T1=A2-M2 Equation (1) 

T2=A3-M3-T1 Equation (2) 

T3= A4-M4-T1-T2 Equation (3) 

T4=M5 (or) A5-T1-T2-T3 Equation (4) 



It may be observed from the above that the traffic volimie for each tariff duration 
1 5 may be accurately determined using the two coimts . While the marginal counts (M2 , M3 , 
etc.) are described as being counted from a previous switching point, it may be 
appreciated that the traffic volimie for each duration may be determined accurately even 
if the marginal counts represent counts up to a previous switching point from the time a 
previous accounting record is sent. 
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In addition, SSG 150 may enable the counts to be sent only once and at any time 
point in each tariff duration, which may thus reduce the processing overhead on a SSG. 

In general, a packet format is needed to send the counts (or accoxmting records). 
Similarly, packet format is needed to send the tariff switching points as well. An example 
5 packet is described below in further detail. 

6. Packet Formats 

In an embodiment, SSG 150 and AAA server 140 exchange packets using 
RADIUS protocol described in further detail in RFC 2865, noted above. Accordingly, 
various extensions may be provided within the firame-work of RADIUS protocol to 
10 support various features of the present invention, as described below in further detail. 

As described in RFC 2865, several attributes may be sent from/to AAA server 1 40, 
with potentially several attributes cascaded in sequence in the same packet. Some of the 
attributes are pre-defined and some can be defined by a vendor (referred to as vendor- 
specific attributes). With respect to sending aggregate and marginal counts, the pre- 
15 defined attributes can be used to send aggregate counter values. However, a vendor 
specific attribute may need to be defined to send marginal counts and to specify the tariff 
switching points as described below. 



The following packet format may be used for vendor specific attributes: 
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Byte 1 : 26 (to indicate that the attribute is vendor specific) 
Byte 2: the length of the attribute in octets 

Bj^es 3-6: Vendor identifier (Can be set to a value of 0 in the high-order octet (byte 3) 
and the lower order 3 bytes may be set to a value reflecting SMI Network 
5 Management Private Enterprise Code of the vendor in network byte order (e.g., 9 

to indicate Cisco Systems, the assignee of the subject patent application) as 
defined in RFC 1700 entitled, "Assigned Numbers") 

Byte 7: Identifier of the attribute (described below) 

As relevant to the description above, byte 7 can take on one of two values, one 
10 value (e.g., 253) for marginal count and another value (e.g., 25 1) for data representing the 
switching points. The remaining packet content depends on whether byte 7 indicates that 
the attributes relates to marginal coxmt or switching points, as described below with 
examples. 

The remaining packet content for data representing the switching points is 
1 5 described below first. 

Byte 8: Length of the present sub-attribute; 

Bj^e 9: Code of to indicate that the service is a payment type; 

Byte 10: Code of to indicate that the service is a post-paid service; 

Byte 1 1 : Code of ' W to indicate that the tariff data represents a weekly tariff switch plan 
20 specification; and 
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Byte 12-23: Weekly tarifif switch point/time specified in 'hh:mm:ss:d' format, wherein 
hh = hour of day <0-23>5 mm = minutes <0-59>, ss = seconds <0-59>, and d = 
bit-map (described below) format for the days of week. The bit map may also be 
converted into a three digit number, and each digit may be encoded in a byte. 

The bit map (d above) represents a value containing seven bits, with each bit 
specifying whether the switching point is applicable to a corresponding day in the week. 
Thus, a value "001 1 1 11 " (= 03 1 decimal) specifies that the switching point is applicable 
to Monday, Tuesday, Wednesday, Thursday and Friday, assuming that the first bit relates 
to Saturday. Similarly, tariff data of "PPWOO:00:00: 127" represents tariff switch time 
each day a week at midnight. Bytes 1 2-23 may be repeated as many times as the number 
of switching points. 

With respect to requests related to marginal count, the remaining bytes may be 
defined as follows: 

Byte 8: Length of the present sub-attribute; 

Byte 9: set to 'Q' to indicate that the control information code for post-paid service data; 
Byte 10: set to 'B' to indicate that the below data indicates traffic volume used since last 
switching point; 

Bytes 11-12: The traffic volume (byte count, number of packets) since the last switching 

point (specified in the following bytes); and 
Byte 13 Onwards: The previous tariff switching time/point in Unix time stamp format. 
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With respect to sending aggregate counter values, the attributes described in RFC 
2866 entitled, "RADIUS Accounting", available at www.ietf.org, may be used. Similarly, 
when the service access session(s) are terminated, an accoimting stop record containing 
the final aggregate count and marginal coimt may be sent. 

Merely for simplicity, a traffic volume type (e.g., total bytes transferred) is 
described as being sent. However, depending on the billing requirements, data 
representing other types of traffic volume (merely bytes sent or received, or packets sent 
or received) may also be sent in accounting records. In addition, each accounting record 
may be sent in one or more IP packets. 

Based on the values in the two attributes, AAA server 140 may determine the 
traffic volume used in each tariff duration and compute the bill based on tariff 
corresponding to each subscriber. Thus, the packet formats described above can be used 
to implement various aspects of the present invention. Example embodiments of SSG are 
described in fiirther detail below. 

7. Service Selection Gateway 

Figure 4 is a block diagram illustrating the details of an embodiment of service 
selection gateway (SSG) 1 50 as relevant to various aspects of the present invention. SSG 
150 is shown containing inbound interfaces 410, parser block 420, routing block 430, 
forwarding block 440, tariff block 460, tariff tables 465, accounting block 470, counters 
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block 480, and outbound interfaces 490. Each component is described in further detail 
below. 

Inbound interfaces 410 provide the electrical, physical, and protocol interfaces to 
receive data packets from various subscriber systems, AAA servers, service networks, 
5 SESM, etc. The received packets are forwarded to parser block 420 in appropriate format 
(e.g., IP packets). Similarly, outboimd interfaces 490 provide the electrical, physical, and 
protocol interfaces to send data packets to various subscriber systems, AAA servers, 
service networks, SESM, etc. Both inboxmd interfaces410 and outbound interfaces490 
may be implemented in a known way. 

1 0 Parser block 420 examines each received packet and forwards the received packets 

to one of routing block 430, forwarding block 440 and traffic block 460. The specific 
component to forward to depends generally on the destination address and other header 
contents. Parser block 420 may be implemented in a known way. 

Routing block 430 receives packets related to various routing protocols (OSPF, 
15 RIP, etc.) and populates the entries in forwarding tables 435. The entries in forwarding 
tables 435 may be configured manually as well. In general, the entries specify the manner 
(next hop address and/or specific interface) in which each IP packet is to be 
forwarded/processed. Routing block 430 may be implemented in a known way. 
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Forwarding block 440 receives packets from parser block 420 and accounting 
block 470, and forwards each received packet based on the destination address contained 
in the packet. In general, the specific interface on outbound interfaces 490 on which to 
transmit a packet, is determined by accessing forwarding tables 435. 

Tariffblock 460 receives packets related to tariff data containing various switching 
points and populates the entries in tariff tables 465. In general, the entries specify the 
appUcable switching points for different tariffs. 

Counters block 480 represents various counters which may ne^d to be maintained 
to support tariffs according to various aspects of the present invention. In an 
embodiment, counters block 480 contains two counters for each session/subscriber, with 
one counter being used for the marginal count and another counter for the aggregate 
count. An altemative embodiment may be implemented using only a single counter for 
each session/ subscriber as described below. 

Accounting block 470 receives information (e.g., byte count, source IP address, 
destination IP address, etc.) on various packets, and updates the corresponding counters 
in counters block 480. Also, the coimter values may be sent at any convenient time in 
each switching duration to facilitate accurate computation of the applicable charges 
(according to the different tariffs). 
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In an embodiment in which a coimter is maintained associated with each of 
aggregate count and marginal count, the values in the counters may simply need to be 
copied and sent in the appropriate format in a corresponding accounting record. Thus, 
the task of sending accounting records may be simplified, but the computation (and 
register) overhead of maintaining two counters may be unacceptably high. 

Accordingly, in an alternative embodiment, only a single counter is used for the 
aggregate count, and the value in the coimter may be stored in a variable at each 
switching point. The marginal count may then be computed by subtracting the stored 
value (in the variable) fi-om the aggregate count at the time of sending an accoimting 
record. 

Thus, the embodiment of Figure 4 can be used to provide flexible billing support 
as may be desirable in various environments. It should be understood that the different 
components of an SSG can be implemented in a combination of one or more of hardware, 
software and firmware. In general, when throughput performance is of primary 
consideration, the implementation is performed more in hardware (e.g., in the form of an 
application specific integrated circuit). 

When cost is of primary consideration, the implementation is performed more in 
software (e.g., using a processor executing instructions provided in software/firmware). 
Cost and performance can be balanced by implementing SSG 150 with a desired mix of 
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hardware, software and/or firmware. An embodiment implemented substantially in 
software is described below. 

8. Software Implementation 

Figure 5 is a block diagram illustrating the details of SSG 1 50 in one embodiment. 
5 SSG 150 is shown containing processing unit 510, random access memory (RAM) 520, 
secondary memory 530, output interface 560, packet memory 570, network interface 580 
and input interface 590. Each component is described in fiirther detail below. 

Input interface 590 (e.g., interface with a key-board and/or mouse, not shown) 
enables a user/administrator to provide any necessary inputs to SSG 150. Output 
10 interface 560 provides output signals (e.g., display signals to a display unit, not shown), 
and the two interfaces together can form the basis for a suitable user interface for an 
administrator to interact with SSG 150. 

Network interface 580 may enable SSG 150 to send/receive data packets to/fi-om 
other systems ( 1 1 0, 1 20, 1 30, 1 40, 1 70, and 1 80) on corresponding paths using protocols 
15 such as internet protocol (IP). Network interface 580, output interface 560 and input 
interface 590 can be implemented in a known way. 



RAM 520, secondary memory 530, and packet memory 570 may together be 
referred to as a memory. RAM 520 receives instructions and data on path 550 (which 
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may represent several buses) from secondary memory 530, and provides the instmctions 
to processing unit 510 for execution. In addition, the variables and counters described 
above may be maintained in the memory. 

Packet memory 570 stores (queues) packets waiting to be forwarded (or otherwise 
processed) on different ports. Secondary memory 530 may contain units such as hard 
drive 535 and removable storage drive 537. Secondary memory 530 may store the 
software instructions and data, which enable SSG 150 to provide several features in 
accordance with the present invention. 

Some or all of the data and instructions may be provided on removable storage unit 
540 (or from a network using protocols such as Intemet Protocol), and the data and 
instructions may be read and provided by removable storage drive 537 to processing unit 
510. Floppy drive, magnetic tape drive, CD-ROM drive, DVD Drive, Flash memory, 
removable memory chip (PCMCIA Card, EPROM) are examples of such removable 
storage drive 537. 

Processing unit 510 may contain one or more processors. Some of the processors 
can be general piupose processors which execute instmctions provided from RAM 520. 
Some can be special purpose processors adapted for specific tasks (e.g., for 
memory/queue management). The special purpose processors may also be provided 
instructions from RAM 520. 
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In general, processing unit 510 reads sequences of instructions from various types 
of memory medium (including RAM 520, storage 530 and removable storage unit 540), 
and executes the instmctions to provide various features of the present invention 
described above. 

It may be appreciated that the features of above may be useful in several situations. 
For example, a service provider may offer a post-paid service (i.e., subscribers use the 
service first, and then are charged), which subscribers are charged 

9. Conclusion 

While various embodiments of the present invention have been described above, 
it should be understood that they have been presented by way of example only, and not 
limitation. Thus, the breadth and scope of the present invention should not be limited by 
any of the above-described exemplary embodiments, but should be defined only in 
accordance with the following claims and their equivalents. 
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